AI时代做需求分析的常见提示词
你会学到什么
第4章讲了提示词的通用原理（五大要素、CoT、Few-shot），第5章讲了需求分析的完整流程。本节聚焦具体场景的提示词模板——你可以直接复制使用的竞品分析、功能规划、用户故事、技术方案提示词，以及如何组合它们完成从想法到结构化需求的全流程。
同样一句"帮我做个需求分析"，有人拿到的只是一堆正确的废话，有人拿到的是可以直接开干的功能清单——差距全在提示词上。需求分析本质上是站在产品视角思考，技术人员写好这类提示词，恰恰是理解"偏业务方向的提示词怎么写"的最佳练习。
需求分析提示词为什么不一样
给AI写"生成一个登录组件"这种提示词，它直接就给你代码了。但需求分析阶段的提示词不一样——你需要让AI做发散→收敛的思考，而不是直接输出代码。
两个关键差异：
| 编码提示词 | 需求分析提示词 |
|---|---|
| 目标：得到代码/具体方案 | 目标：得到结构化思考和选项 |
| 单次交互即可完成 | 需要多轮迭代验证 |
| 输出格式固定（代码/接口） | 输出格式灵活（表格/清单/文档） |
| 技术上下文优先 | 业务+技术上下文并重 |
需求分析提示词的核心特征：
- 明确输出格式：告诉AI用表格、清单还是结构化文档输出
- 给出参考锚点：指定竞品名称、技术栈、约束条件，避免AI泛泛而谈
- 要求给出理由：不只让AI说"做什么"，还要问"为什么"
- 预留迭代空间：提示词要支持基于上一次输出继续细化
再补两层背景，帮你看清这张表背后的"为什么"：
目标形态不同。编码提示词目标明确——"按这个格式帮我生成一个 Skill"，一次交互就能把指令交代得非常清楚；需求分析的目标却是先发散再收敛：你现在要做一个东西，但可能还不知道怎么做才好、怎么做才跟竞品有差异、又能吸收别人优秀的地方。技术人员在这里容易走两个极端：要么过度依赖AI，要么用纯理工科的直线思维硬扛——跳出这两个极端，正是结构化思考的要害。
交互历史不同。早期 ChatGPT 上下文长度有限，一份完整的需求分析文档要靠多轮对话一点点拼出来，前后关联还常常断裂。现在的正确做法是：给出清晰指令的同时，明确告诉AI什么能做、什么不能做。Anthropic 官方的 /doc-coauthoring 交互式文档技能（第6章介绍过）就是这一思路的官方实现——通过多轮对话持续收集需求，让AI聚焦你的约束条件，避免谈得太泛。
下面按场景给出四个可直接使用的模板。
模板一：竞品分析提示词
适用场景
- 项目启动时需要了解市场格局
- 功能设计时想参考竞品怎么做
- 技术选型时需要对比不同方案
基础模板
请分析【竞品名称】在【具体领域】的实现，帮我完成以下分析：
1. 功能覆盖：列出核心功能模块，标注完成度（完整/部分/未实现）
2. API设计风格：分析其命名习惯、Props结构、事件处理方式
3. 技术栈：用的框架、构建工具、样式方案
4. 差异化亮点：找出它与其他竞品不同的3-5个设计点
5. 可借鉴之处：列出3-5个我们可以学习的设计决策
要求：
- 输出markdown表格
- 具体到"XX组件的XX属性采用XX命名"的程度
- 对于API设计，给出具体代码示例对比
text
进阶模板：横向对比多个竞品
请横向对比以下【竞品A】、【竞品B】、【竞品C】，聚焦【具体功能/领域】：
对比维度：
1. 功能实现方式：各自采用什么技术方案实现？优劣对比
2. API易用性：从开发者角度，哪个更直观？为什么？
3. 扩展性：哪个设计更便于后续扩展？具体体现在哪里？
4. 性能表现：有无公开的性能对比数据或benchmark？
输出格式：
- 先给出总体结论（一句话总结）
- 再用表格对比各维度
- 最后给出选型建议（如果你的项目是【你的项目描述】，建议选择XX路线，理由XXX）
注意：
- 不要泛泛而谈，要指出具体的API/设计差异
- 对于API差异，用代码示例说明
- 如果需要最新数据，请先搜索确认
text
先发散再打分：一个最小可用的示例
不确定对比维度怎么写时，不用自己憋——直接问AI要维度：
我要评判组件库这类产品，从技术和产品两个角度，
业界通行哪些评判维度？给我一组维度，并列出几个业界优秀的产品。
text
拿到维度后，套"生成候选 → 按维度打分 → 综合分排序"的模式。用一个最浅显的例子看懂它——让AI为一个小男孩起几个寓意好的英文名：
为一个小男孩生成几个好用的英文名称，要求有好的寓意。
（拿到候选后，追加一条）
从以下几个维度对上面的名称进行分析，给出综合评分：
寓意、读音、书写，依次打分，最后给一个综合分，按倒序排列。
text
AI会输出一张打分表格，标注每项得分并给出综合排名。把"英文名"换成"竞品名称"、"寓意/读音/书写"换成"功能覆盖/API易用性/生态/性能"，就是一次标准的竞品横向对比。这个模式适用于一切"多个候选 + 多个维度"的场景——数据统计分析、方案评选、模型选型都一样。
实战：让Claude Code自动组队调研Vue3组件库
在装有 local-search 搜索技能（第5章02节）的 Claude Code 里，把进阶模板里的占位符换成真实竞品：
请横向对比 Element Plus、Ant Design Vue、shadcn-vue、Naive UI，
聚焦"AI组件库"这个领域：
对比维度：
1. 技术方案优劣（SFC模板 / design tokens / copy-paste / CSS-in-JS主题）
2. 上手难度
3. 对做AI对话/聊天类产品的适配度
要求：
- 先用 local-search 搜索补充最新上下文，再做竞品分析
- 输出总体结论 → 对比表格 → 选型建议
text
实测中，Claude Code 自发组建了4个并行 Agent 分头调研——我没有要求它组队，它从 CLAUDE.md 和历史对话里已经熟悉了我的工作习惯。如果你的环境没有这么"自觉"，在提示词里写明即可："你自己组建一个团队，使用本地搜索工具提供上下文，对上面的组件库进行并行调研，再合并结论。"
AI给出的选型结论（与我们的判断高度贴合）：做AI对话/聊天类产品，首选 shadcn-vue——AI组件丰富、与 Vercel AI SDK 生态深度集成，现在的很多AI建站工具都基于它的 copy-paste 模式；通用后台管理系统选 Element Plus（SFC 模板最符合 Vue 开发习惯）；数据密集型选 Naive UI（纯 CSS-in-JS 主题系统，运行时动态计算 CSS 变量，不依赖任何预处理器）；企业级设计规范选 Ant Design Vue（design tokens 最企业级的主题方案）。另外注意：Tailwind CSS 不是UI组件库而是原子CSS库，不放进组件库对比清单。
使用要点
- 竞品名称要具体：不要说"主流组件库"，要说"Element Plus、Naive UI、Shadcn-Vue"
- 聚焦具体功能：不要问"分析整个组件库"，要问"分析它们的Form表单验证方案"
- 代码示例分阶段：初期的概览分析不必要求；深入不熟悉的技术方案时再要求给出代码示例——主要看代码风格与你熟悉的是否一致、可读性强不强、你能否接受
- 让AI搜索最新数据：技术栈、版本号这些信息，提示AI先搜索再分析
模板二：功能规划提示词
适用场景
- 从用户需求推导功能清单
- MVP阶段需要决定先做什么、后做什么
- 需要评估开发成本和优先级
基础模板
我正在做一个【项目类型】，目标是【核心目标】。
约束条件：
- 【时间约束】：如一个人、2个月业余时间
- 【资源约束】：如已有XX组件库基础，需要兼容XX浏览器
- 【范围约束】：如只覆盖中后台场景，不做移动端
请帮我：
1. 列出功能清单，按【分类方式】分类
2. 对每个功能标注：
- 优先级：P0（必须有）/ P1（应该有）/ P2（可以有）
- 开发复杂度：低（<X小时）/ 中（X-Y小时）/ 高（>Y小时）
- 依赖关系：是否依赖其他功能
3. 给出开发分批建议：
- 第一批：低成本+高价值的功能
- 第二批：高频使用的中等复杂度功能
- 第三批：复杂但必要的功能
输出：markdown表格，包含功能名称、分类、优先级、复杂度、依赖、批次
text
进阶模板：从用户痛点推导功能
目标用户面临以下痛点：
1. 【痛点1描述】
2. 【痛点2描述】
3. 【痛点3描述】
当前市场上【竞品或现状】的不足是：【具体不足】。
约束条件：
- 【项目约束】
请从用户痛点出发，逆向推导功能清单：
1. 对每个痛点，列出可能的解决方案（2-3个选项）
2. 评估每个方案的：开发成本、用户价值、技术风险
3. 给出推荐方案及理由
4. 生成最终功能清单表格（包含：痛点、解决方案、功能名称、优先级、复杂度）
输出格式：
- 先列出痛点→解决方案的推导过程
- 再给出最终功能清单表格
text
使用要点
- 约束条件越具体越好：不要说"时间有限"，要说"200小时可用时间"
- 让AI给多个方案：不要直接要一个清单，让AI先给出2-3个选项，你再决策
- 要求给出理由：优先级判断和复杂度评估都要让AI说明原因
- 基于你自己的经验调整：AI给出的复杂度估算可能不准，需要你根据实际情况修正
模板三：用户故事生成提示词
适用场景
- 需要将功能需求转化为可验收的用户故事
- 敏捷开发中需要明确的验收标准
- 与团队对齐需求时需要具体场景描述
基础模板
基于以下功能需求：【功能描述】
请生成用户故事，格式如下：
**用户故事X：【简短标题】**
- **作为**【角色】
- **我想要**【需求】
- **以便**【价值】
**验收标准：**
- Given【前置条件】
- When【操作】
- Then【预期结果】
**边界情况：**
- 如果【异常情况】，应该【处理方式】
要求：
- 每个用户故事只包含一个核心功能
- 验收标准要具体到"点击按钮后显示XX文字"的程度
- 至少包含3个边界情况
text
进阶模板：让AI扮演用户验证用户故事
请扮演【用户类型】的用户，验证以下用户故事是否合理：
【用户故事内容】
验证问题：
1. 这个故事描述的场景是否真实？是否有更常见的场景被忽略？
2. 验收标准是否清晰？是否有需要查文档才能理解的地方？
3. 边界情况是否完整？补充你想到的其他边界情况
4. 从用户体验角度，这个功能设计是否直觉？有什么改进建议？
输出格式：
- 先指出当前用户故事的优点
- 再列出需要改进的地方（具体到措辞）
- 如果发现重大问题，给出重写建议
text
使用要点
- 角色要具体：不要说"作为用户"，要说"作为没有编程经验的产品经理"。最典型的场景是写PPT大纲：受众是不懂技术的领导时，要突出商务价值、绩效和团队能力，而不是死板的技术堆叠——领导看不懂。配置好全局 CLAUDE.md 后，AI了解了你的技术背景，回答时会主动挑你能理解的话术和领域知识来对话（第3章讲过的"系统级提示词"效果）
- 验收标准要可测试：每个Given-When-Then都要能写成自动化测试
- 让AI扮演挑剔用户：验证时让AI扮演不同水平的用户，发现直觉性问题
- 迭代优化：用户故事不是一次性写完的，用AI验证后持续改进
模板四：技术方案提示词
适用场景
- 从功能需求推导技术选型
- 需要设计API接口规范
- 需要规划项目架构和目录结构
基础模板：技术选型
我要做一个【项目描述】，功能需求是：【核心功能】。
约束条件：
- 技术栈：【已选定的技术】
- 团队规模：【团队情况】
- 时间约束：【交付时间】
- 特殊要求：【如SSR/IE11支持/包体积限制】
请帮我完成技术选型：
1. 【技术领域A】：对比【方案A】、【方案B】、【方案C】
- 从以下维度评估：学习曲线、生态成熟度、性能、长期维护性
- 给出推荐方案及理由
2. 【技术领域B】：同上
3. 关键技术风险：列出可能的技术难点及应对方案
输出格式：
- 先给出总体技术栈结论
- 再分领域说明选型理由
- 最后列出风险和应对方案
text
进阶模板：API设计规范
请为我的【项目类型】制定API设计规范。
参考对象：【列出2-3个竞品或类似项目】
约束条件：
- 技术栈：【如Vue3 + TypeScript】
- 风格偏好：【如偏向React Hooks风格的命名】
- 特殊要求：【如Props不超过8个、支持SSR】
请制定：
1. Props命名规范
- 和HTML原生属性保持一致的原则（举例说明）
- 和框架惯例一致的原则（举例说明）
- Boolean prop的默认值约定
- 禁用的命名模式（如不要用什么前缀）
2. Events规范
- v-model相关事件的命名
- 自定义事件的命名
- 是否透传原生事件
3. Slots规范
- 默认slot的使用约定
- 具名slot的命名约定
4. TypeScript类型定义规范
- 是否使用泛型
- 如何处理可选属性
- 导出类型的组织方式
要求：
- 分析参考对象的优缺点
- 规范要具体到"遇到XX情况应该用XX命名"的程度
- 给出具体代码示例
text
选型是分层递进的：一个真实对话路径
做过一两个技术项目的人，技术方案提示词都不难写——项目背景、核心功能、技术栈、团队构成、工期，这些你本来就说得清楚。难得的是把选型拆成递进的层次，一层一层收敛。一个真实对话：
【第一轮：交代团队背景，定大方向】
我们团队前端 Vue 和 React 都有人熟悉，比例大概6:4。
现在要做一个全栈项目，前后端都做。后端技术怎么选？
text
做过技术方案的人（以及AI）都会给出同一个答案：Node.js——前后端语法一致，团队成员稍微了解一下服务端知识就能上手，切换成本最低。
【第二轮：在定下的大方向里继续细化】
后端定了 Node.js。那 API 框架在 Express / Fastify / Hono 里怎么选？
从学习曲线、生态、性能三个维度对比，给出推荐和理由。
text
大方向定了，具体方案再细致讨论——这正是下面"约束注入"策略在技术选型里的应用。
使用要点
- 给出参考对象：不要让AI凭空设计，告诉它参考Element Plus还是Shadcn-Vue
- 明确风格偏好：API设计有风格差异，告诉AI你偏向哪种风格
- 要求对比分析：让AI分析参考对象的优缺点，再给出你的规范
- 用Context7查最新文档：技术选型时，用Context7查最新版本文档，不要让AI靠训练数据
提示词组合策略
单个提示词解决不了完整的需求分析。实战中需要组合使用多个提示词，形成"发散→收敛"的思考链路。
先说一个宽心的话：不必背下所有模板。看到四个模板就发懵"到底用哪个"，是正常的第一反应——你真正要理解的是思维，而不是清单：什么场景要让模型发散、什么场景要收敛、什么时候需要强角色扮演、什么时候需要明确约束。随着项目做多了、与AI的对话多了，它会越来越熟悉你的习惯——前面组件库的案例里，我没有要求它用 local-search 补上下文，也没要求它组队并行调研，它都自己做了。摸清了这些，你遇到新场景自然知道怎么约束模型的输出。
策略一："发散→收敛"两阶段法
第一阶段：发散探索
我想做一个【项目类型】，目标是【核心目标】。
请从以下角度发散分析：
1. 市场上有哪些类似产品？分别采用什么技术路线？
2. 如果是我做，有哪3-5种可能的实现方向？
3. 每种方向的核心技术难点是什么？
不要给结论，先列出尽可能多的选项和维度。
text
第二阶段：收敛决策
基于上一轮的探索，我选择【XX方向】。
约束条件是：【具体约束】
请帮我：
1. 验证这个选择是否合理（列举支持理由和潜在风险）
2. 给出具体的实现方案（技术栈、API设计、开发排期）
3. 列出前3个优先级最高的功能及验收标准
text
策略二："角色扮演"法
让AI分别扮演不同角色，从不同视角分析需求：
【第一轮：产品经理视角】
请扮演产品经理，基于以下需求：【需求描述】
输出：
1. 用户画像：3类典型用户及其核心诉求
2. 功能清单：按优先级排列
3. 不做什么：明确排除的功能及理由
---
【第二轮：开发者视角】
请扮演开发者，基于上面的产品产出物
输出：
1. 技术选型建议
2. API设计规范（Props/Events/Slots）
3. 开发排期估算
4. 技术风险和应对方案
---
【第三轮：QA视角】
请扮演QA，基于上面的产品和技术方案
输出：
1. 每个功能的验收标准
2. 需要重点测试的场景
3. 可能的边界情况和异常处理
text
策略三："约束注入"法
在提示词中逐步加入约束条件，让AI在约束下寻找最优解：
【第一轮：无约束】
我要做一个【项目】，请给出技术方案建议。
---
【第二轮：加入技术栈约束】
基于上一轮的建议，但我必须使用【技术栈】，
请调整技术方案。
---
【第三轮：加入时间约束】
如果只有【时间限制】，请调整功能优先级和开发计划。
---
【第四轮：加入资源约束】
如果只有【团队规模】，请调整技术选型和架构设计。
text
实战案例：用提示词分析AI组件库需求
以"做一个AI增强的Vue3组件库"为例，展示完整的提示词链路。整条链路五步走完：竞品分析 → 功能规划 → API设计 → 用户验证 → 生成文档。
动手前两点提醒：
- 竞品分析本身是发散的，需要大范围搜索。编码套餐自带的搜索功能发散能力不足，要配合本地搜索引擎（第5章02节的 local-search）扩展上下文；网络上搜罗完方案之后，更重要的一步是把竞品源码交给AI深读剖析——这正是下一节的内容。
- 生成文档环节不展开。产品需求文档、技术方案文档的生成——用 MCP、创建各式各样的 Skill、确定文档风格——第6、7章已详细讲过，此处不重复。
第一步：竞品分析（发散）
请分析当前市场上支持AI功能的前端组件库：
重点分析：
1. 有哪些组件库已经集成了AI能力？（用搜索确认）
2. 它们的AI功能是什么形式？（AI生成组件、AI辅助配置、AI对话式表单等）
3. 技术实现方式？（前端调用AI API vs 后端服务）
4. API设计：AI相关功能如何暴露给开发者？
输出：
- 表格对比各组件库的AI功能
- 总结当前市场的空白点
text
AI输出示例（需人工审核）：
| 组件库 | AI功能 | 实现方式 | API风格 |
|---|---|---|---|
| Vercel AI SDK | AI对话UI组件 | 流式SSE | React Hooks |
| Shadcn/ui | AI生成组件代码 | 调用OpenAI API | CLI命令 |
| （空白） | （空白） | （空白） | （空白） |
发现：目前没有专门的"AI增强型Vue3组件库"，空白点是：AI辅助表单填写、AI生成配置、AI对话式组件选择器。
第二步：功能规划（收敛）
基于上面的竞品分析，我要做一个AI增强的Vue3组件库。
聚焦空白点：AI辅助表单填写 + AI生成组件配置
约束条件：
- Vue 3.5 + TypeScript
- 开发者通过环境变量配置自己的AI API Key
- 核心包gzip不超过50KB（不包含AI逻辑）
- 一个人开发，2个月业余时间（约200小时）
请帮我：
1. 列出MVP功能清单（15-20个功能点）
2. 对每个功能标注优先级和开发复杂度
3. 给出开发分批建议
输出：markdown表格
text
AI输出示例（部分）：
| 功能 | 优先级 | 复杂度 | 说明 |
|---|---|---|---|
| AI表单自动填写（基于上下文推断） | P0 | 高 | 核心差异化功能 |
| AI配置生成器（自然语言→Props） | P0 | 中 | 开发者体验 |
| 基础组件（Button/Input等） | P1 | 低 | 依赖AI功能的载体 |
| AI对话式组件选择器 | P2 | 高 | nice to have |
第三步：API设计（具体化）
为"AI配置生成器"功能设计API。
功能描述：开发者用自然语言描述想要的组件样式，
AI生成对应的Props配置。
参考对象：Vercel AI SDK的useChat hook
约束条件：
- Vue 3.5 Composition API
- TypeScript严格模式
- 流式输出（打字机效果）
- 支持自定义AI API endpoint
请设计：
1. Composable函数签名（useAIGenerator）
2. 返回值的类型定义
3. 使用示例（2-3个场景）
要求：
- Props不超过6个
- 符合Vue 3组合式API惯例
- 给出完整的TypeScript类型定义
text
AI输出示例（需人工审核）：
interface AIGeneratorOptions {
apiKey: string
endpoint?: string // 默认OpenAI
model?: string // 默认gpt-4
systemPrompt?: string // 自定义系统提示词
}
interface AIGeneratorReturn {
config: Ref<Record<string, any>> // 生成的配置
isGenerating: Ref<boolean>
error: Ref<string | null>
generate: (input: string) => Promise<void>
stop: () => void
}
function useAIGenerator(
componentName: string,
options: AIGeneratorOptions
): AIGeneratorReturn
typescript
第四步：用户验证（迭代）
请扮演两个不同水平的开发者，验证下面的API设计：
【API设计内容】
【新手开发者】只用过Vue，没用过AI API：
- 尝试使用这个API生成一个Button组件的配置
- 遇到任何不理解的地方，标记出来
【有经验开发者】用过Vue3 + TypeScript：
- 尝试为Select组件生成配置
- 从类型安全角度评估这个API
- 指出设计上的可改进之处
输出：
- 每个角色使用API时遇到的问题
- API设计的改进建议
text
AI输出示例：
新手开发者问题：
- "不知道endpoint怎么填，需要示例"
- "systemPrompt不知道该写什么"
有经验开发者问题：
- "config类型是Ref<Record<string, any>>太宽泛，应该根据componentName推导类型"
- "缺少流式输出的回调"
人工决策： 根据反馈简化API（endpoint给默认值），加强类型（泛型推导），添加onChunk回调。
第五步：生成文档
基于前面的所有讨论，生成两份文档：
【产品需求文档】
1. 产品定位（2-3句话）
2. 目标用户画像（2类）
3. MVP功能清单表格
4. 开发分批计划
5. 成功标准
【技术方案文档】
1. 技术栈确认
2. API设计规范摘要
3. 项目目录结构
4. 关键技术决策及理由（为什么选择流式输出、为什么要求配置API Key等）
5. 技术风险和应对方案
输出：两份独立的markdown文档
text
本节要点
- 需求分析提示词的核心：让AI做"发散→收敛"的思考，而不是直接输出代码。关键是明确输出格式、给出参考锚点、要求给出理由。
- 四类核心模板：竞品分析（对比市场）、功能规划（从需求到清单）、用户故事（验收标准）、技术方案（选型+API设计）。每个模板都可以直接复制使用。
- 提示词是组合使用的：单个提示词解决不了完整需求分析。实战中用"发散→收敛"两阶段法、"角色扮演"法、"约束注入"法组合多个提示词。
- AI输出必须人工审核：特别是时间估算、优先级判断、技术选型这些关键决策。AI帮你把思考变成结构化文档，但决策权在你。
- 让AI搜索最新数据：竞品分析、技术选型时，提示AI先用搜索工具获取最新信息，不要只靠训练数据。
- 参考对象要具体：不要让AI泛泛而谈，给出具体的竞品名称、技术栈、风格偏好。参考对象越具体，输出越可用。
- 迭代优化是常态：用户故事、API设计都不是一次性写完的。让AI扮演不同角色验证，持续改进。
- 维度不确定就先问AI：竞品对比不知道从哪些维度切入时，先让AI给一组业界通用的评判维度，再套"生成候选→按维度打分→综合分排序"的模式。
↑